ISO-15288, OOSEM and Model-Based Submarine Design

When tasked with the development of a large and complex system of systems it is necessary that a project operates according to current best practice in all domains including systems engineering. These practices have been documented by organisations such as INCOSE and the International Organisation for Standardisation (ISO). Model-based systems engineering (MBSE) is currently considered a best practice approach to the specification, design, analysis and verification of a complex system. A model-based design approach can leverage the benefits of a system model to integrate multiple domains in a more precise, consistent, traceable and re-usable format than traditional document-centric design processes. ISO-15288, published by ISO, is a world-wide standard for systems and software engineering lifecycle processes. This standard defines a framework of processes that can be applied to a system throughout its full lifecycle, including requirements definition and analysis, architectural design, implementation and verification. The Object-Oriented Systems Engineering Method (OOSEM) was developed in 1998 and has since been refined by the INCOSE OOSEM Working Group and others. When applied in conjunction with the Systems Modelling Language (SysML), OOSEM is widely advocated as an example of MBSE best practice. In Deep Blue Tech (DBT), submarine concept formulation activities are supported by a framework of model-based SE processes. Motivated by the introduction of MBSE to a requirements analysis and design team, a study was undertaken to explore a mapping between DBT design processes and the integrated processes defined in OOSEM and ISO-15288. This paper will discuss a number of observations from the study and how they were used to update DBT processes to enable a successful development strategy. INTRODUCTION A military submarine is a very complex system-of-systems. Most of these systems are integrated within the confines of a pressure hull. This key constraint means that most submarine systems are highly coupled, physically and often operationally. This leads to emergent behaviour and properties that are often as undesirable as they are unintended. Further complicating this situation, the increasing fraction of embedded software and the integration of COTS equipment in submarine systems require a design that accommodates frequent hardware and software upgrade cycles (Mitchell 2010). The submarine designer performs a critical and centralising role within an enterprise of many organisations generating, integrating and evolving design information at every level of the submarine design. In order to execute this role and deliver value for money, the designer must be equipped with the best available personnel, tools and processes. In late 2007, Deep Blue Tech was established as a wholly-owned subsidiary of the Australian submarine and shipbuilding organisation, ASC. The mission of DBT is to be “the designer for the entire lifecycle of Australia's Future Submarine” (DBT 2012). Towards this end, DBT conducts research and development of concepts for Australia’s Future Submarine as outlined in the 2009 Defence White Paper (DWP 2009). DBT has expended considerable effort researching and understanding the latest technology and industry best practice relating to submarine systems design (Wicklander 2012). It was recognised very early in the formation of DBT that there is a strong need to communicate and coordinate the design products and processes deployed across the submarine enterprise. DBT continues to evolve a framework of processes to support the requirements definition and concept design phases of the anticipated submarine project. In pursuit of industry best practice, this framework has been compared with the international standardised framework of system lifecycle processes defined in ISO-15288 (ISO/IEC 2008) and the INCOSE Object-Oriented Systems Engineering Method (OOSEM) (INCOSE 2008). The outputs of traditional submarine design processes are predominantly document-centric, in that much of the engineering design information is captured, indeed locked into electronic text-based reports and drawings. This is a very brittle format and in a high-flux design environment, trying to maintain consistency within a document, let alone across a document set, requires exceptionally high levels of fastidiousness. As a result of this, engineering documentation is often obsolete upon configuration and release. The solution is to manage design information in a more malleable, precise and accessible format: computer models. This is the objective of Model-Based Systems Engineering (MBSE); a paradigm that elevates the 'system model' to prominence as the integrating framework for the 'specification, design and analysis' of a system (Friedenthal et al. 2008). MBSE is becoming bestpractice across a range of industries involved in the development of complex system-of-systems and has been adopted in DBT (Pearce 2011). Applied as a methodology, MBSE is a framework of processes, methods and tools. A number of MBSE methodologies exist, some more or less toolindependent. OOSEM is one tool-independent methodology and was chosen for the study outlined in this paper. If ISO-15288 defines 'what' needs to be done, then OOSEM defines 'how' that can be done, and at their intersection lie the design processes deployed in DBT. This paper will focus on a subset of the technical processes defined in ISO-15288 and OOSEM considered most relevant to the current phase of the Future Submarine project, namely those processes involved with requirements elicitation, requirements analysis and architectural design. Many equally important and cross-cutting processes, such as verification and validation are outside the scope of this paper, but were not absent from the original study. The conclusion to this paper will summarise the most salient lessons and issues covered in the body of this report. ISO-15288 As an international standard, ISO-15288 is intended to harmonise the framework of processes used by any organisation or project throughout the full lifecycle of a man-made system. This standard has its heritage in earlier efforts to standardise systems engineering (SE) processes and products, including systems development (EIA-632) (EIA 1999), and systems engineering management (IEEE-1220) (IEEE 1998). In ISO-15288, SE processes are organised into five groups; Agreement, Enterprise, Project, Technical and Special. The Technical group of SE processes comprises;  Stakeholder Requirements Definition;  Requirements Analysis;  Architectural Design;